With a widespread use of a broadband network, a real-time playback of a large amount of data, such as image data, has been available through data communication. For example, for IP telephones and TV telephones, image data is transmitted together with voice data and is played back in real time at each end of communication. Thus, bi-directional communication is achieved.
A communication method for communicating data in real time is referred to as “streaming communication”. An example of a protocol for streaming is a streaming protocol on TCP, such as HTTP (Hyper Texttransfer Protocol) streaming. In the TCP communication, if packet loss occurs somewhere in a network, the reception side automatically sends a retransmission request. In this way, a reliable packet communication is achieved. That is, in communication using TCP, a retransmission request is automatically sent, and therefore, packets are reliably delivered to a reception application in a proper sequence.
However, in communication using the TCP (Transmission Control Protocol), if a retransmission request frequently occurs, a large delay occurs. Therefore, the TCP communication is not suitable for streaming distribution that requires real-time communication.
In contrast, in streaming distribution over UDP (User Datagram Protocol), such as RTP (Real-time Transport Protocol, RFC3550) streaming, even if packet loss occurs somewhere in a network, the reception side does not basically send a retransmission request. Accordingly, the occurrence of a delay can be reduced. Thus, when real-time communication is required, streaming over the UDP is used, in general. However, in the communication using the RTP or UDP, lost data due to packet loss is not received by the reception application, which is problematic.
To solve this problem occurring for the RTP and UDP, a configuration is proposed in which an application that performs a process of received data can determine that it sends a retransmission request to a streaming transmission side. For example, when the application determines that it needs data in order to perform a stable playback operation, the application requests the streaming transmission side to retransmit the packet. However, if such a retransmission request is sent, a delay occurs as in the above-described case using TCP.
For example, if packet loss occurs during streaming playback and a retransmission request is sent and if a retransmitted packet is not received before a playback process starts, amounts of processing of the transmission side and the reception side increase. Accordingly, it follows that useless packets are disadvantageously sent in the network. To solve such a problem, Patent Document 1 (Japanese Patent No. 3757857) describes a configuration in which only a retransmission request for a “packet that is likely to arrive on time for playback” is sent from the reception side as needed.
For example, when video data is received via the Internet and is recorded (stored), the real-time operation may not be needed. In such a case, in general, a download using HTTP (TCP) in which data is reliably received is used. In contrast, streaming playback is performed and the received streaming data is recorded, a real-time operation in the playback process has priority. Accordingly, in general, a download using HTTP that interferes with real-time playback is not used.
As noted above, an appropriate communication protocol is used for each of a streaming playback process that does not allow the occurrence of delay and a reception data recording process that allows the occurrence of delay. A configuration has not been proposed that realizes a process that meets requirements for these processes (i.e., the streaming playback process and the reception data recording process) and that is appropriate for both the playback process and the recording process.
For example, Patent Document 2 (Japanese Unexamined Patent Application Publication No. 2005-86362) describes a configuration of a recording method used when streaming is performed. However, in the described method, the HTTP is used, and a playback skip is performed if a retransmission request is sent and a delay occurs. Accordingly, the quality of the playback deteriorates.    Patent Document 1: Japanese Patent No. 3757857    Patent Document 2: Japanese Unexamined Patent Application Publication No. 2005-86362